Events! (Reactivity in urbiscript) 



Jean-Christophe Baillie Akim Demaille Quentin Hocquet Matthieu Nottale 
Gostai S.A.S., 15, rue Jean-Baptiste Berlier, F-75013 Paris, France 

http : // www .gostai . com, fi rs t . last® gostai. com 



Abstract — Urbi SDK is a software platform for the devel- 
opment of portable robotic applications. It features the Urbi 
UObject C++ middleware, to manage hardware drivers and/or 
possibly remote software components, and urbiscript, a domain 
specific programming language to orchestrate them. Reactivity 
is a key feature of Urbi SDK, embodied in events in urbiscript. 
This paper presents the support for events in urbiscript. 

Event-based programming is the "native" way in urbiscript 
to program responses to stimuli — a common need in 
robotics. It is typically used for "background jobs that moni- 
tor some conditions". It is used to program the human-robot 
interfaces ("do this when the head button is pushed"), the 
detection exceptional situations (collision avoidance, battery 
level), the tracking of objects of interest etc. Events are also 
heavily used in the implementation of Gostai Studio, a GUI 
for Urbi based on hierarchical state machines [8]. 

In following example "whenever" an object of interest (a 
ball) is visible, the head of the robot is moved to track it. The 
code relies on some of key features of urbiscript: UObjects 
(ball, camera, headPitch, headYaw), concurrency (&), 
and event constructs (whenever). 

whenever (ball . visible) 
{ headYaw. val += camera. xfov * ball.x 
& headPitch . val += camera. yfov * ball.y }; 



I. Urbi and urbiscript 
A. The Urbi Platform 

The Urbi platform [1], including the urbiscript program- 
ming language, was designed to be simple and powerful. It 
targets a wide spectrum of users, from children customizing 
their robots, to researchers who want to focus on complex 
scientific problems in robotics rather that on idiosyncrasies of 
some robot's specific Application Program Interface (API). 

Urbi relies on modularity to provide portability. Com- 
ponents specific to an architecture (sensors and actuators 
drivers, . . . ) are implemented as UObjects, plugged into the 
Urbi core. UObjects can also wrap pure software components 
that provide core services, say text-to-speech, object tracking, 
localization, etc. The C++ UObject architecture is actually a 
middleware: components can be relocated transparently on 
remote computers instead of running on the robot itself. This 
is especially useful for low-end robots whose CPU is too 
limited to run demanding software components (e.g., face 
detection, speech recognition, . . . ). 

The Urbi platform schedules the execution of these UOb- 
jects, routes the events from producers to consumers, and so 
forth. Its core is written in C++. This choice was driven by the 



availability of compilers for many different types of hardware 
architecture, and because many robot SDK are in C/C++. 
It also provides access to very low-level system features 
(such as coroutines, see below), and allows us to program 
their support if they lack, in assembler if needed. Specific 
features of some architectures are also easier to use from 
C/C++, such as the real-time features of Xenomai. Finally, 
some architecture require C++, such the Aibo SDK. 

While the sole Urbi core suffices in many situations, it 
proved useful to provide a programming language to fine- 
tune this orchestration. 

B. The urbiscript Programming Language 

There are already so many programming languages. Why a 
new one? Why not extending an existing language, or relying 
on some library extensions? 

Domain Specific Languages (DSLs) are gaining audi- 
ence because they make developers much more productive 
than when using the library-based approaches. Programming 
robots requires a complete rethinking of the execution model 
of traditional programming languages: concurrency is the 
rule, not the exception, and event-driven programming is the 
corner stone, not just a nice idiom. These observations alone 
justify the need for innovative programming languages. 

There are already many well-established environments that 
provide these features, and that can be used to program 
robots. The world of synchronous languages includes several 
adequate members, such as Lustre [10] or Esterel [3]. These 
systems offer soundness and strong guarantees, but at a price: 
they are very different from the programming languages 
developers are used to. They are adequate to develop real- 
time, life-critical systems, but they are too demanding when 
developing the global behavior of a personal robot. Some 
general purpose programming languages have been extended 
also to offer reactive programming: C [4], Caml [12], Haskell 
[14], etc. 

Since the Urbi core is tightly bound to C++, none of these 
languages are adequate. Binding with low-level languages 
(such as C++) is a domain in which scripting languages, such 
as Python [19] or Lua [11], excel. It is not surprising that they 
are acclaimed interfaces for practical robot programming 
environments such as ROS [15]. 

Yet, they do not provide native support for concurrency 
and reactivity, even if there are existing extensions [6], [17]. 
When the Urbi project was started (circa 2003), the need for a 
new language, tailored for programming robotic applications, 
was felt. 



To cope with the resistance to new languages, urbiscript 
stays in the (syntactic) spirit of some major programming 
languages: C++, Java, JavaScript etc. As most scripting lan- 
guages, it is dynamically typed. 

It is an Object-Oriented Language (OOL): values are 
objects. Unlike most OOLs, urbiscript is not class-based. In 
class-based OOLs (such as C++, Java, C#, Smalltalk, Python, 
Ruby, . . . ), classes are templates (molds) that describe the 
behaviors and members of an object. Classes are instantiated 
to create a value; for instance the Point class serves as a 
template to create values such as one = ( 1 , 1 ) . The object 
one holds the (dynamic) values while the class captures 
the (static) behavior. Inheritance in class-based languages is 
between classes. 

urbiscript is prototype-based, like Self [18], Lisaac [16], 
Cecil [5], Io [7] and others. In these OOLs, there are no 
classes. Instantiation is replaced by cloning: an object serves 
as a template for a fresh object, and inheritance relates 
objects 1 . 



// Create an empty object that derives from Object. 

var one = Ob ject . new ( ) ; 

[00000001] Object_0xl09f ce310 



An object is composed of a list of prototypes (parent 
objects) and a list of slots. A slot maps an identifier to a 
value (an object). 



// one is a clone of Object. 

one .protos; 

[00000002] [Object] 



named 



and 



// Add two slots, 
var one.x = 1; 

[00000003] 1 
var one.y = 1; 

[00000004] 1 

// The names of local slots (inherited slots 
// are not reported) . 

one . locals lot Names; 
[00000005] ["x", "y"] 



urbiscript is fully dynamic. Objects can be extended at 
run-time: prototypes and slots can be added or removed. 
Functions are first-class entities: they are ordinary values 
that can be assigned to variables, passed as arguments to 
functions and so forth, urbiscript supports closures: functions 
can capture references from their environment, then later use 
those references to retrieve or set their content, urbiscript is a 
functional programming language, functions are values that 
can be bound by slot like any other object. 



one ; 

[00000006] Object_0xl09f ce310 

// The function "asString" is used by the system 
// to report values to the user. 

function one . asString ( ) ( " (%s, %s) " % [x, y] }; 

one; 

[00000007] (1, 1) 



'Lines starting with a timestamp such as [00001451] (1.1451s 
elapsed since the server was launched) are output by Urbi; the other lines 
were entered by the user. The system answers with the value of the entered 
expressions, unless there is none (e.g., void). Due to space constraints, 
the system answers for functions (their definition) is not displayed in this 
paper. 



For a thorough presentation of urbiscript, see [9]. 

C. Concurrency 

Today, any computer runs many programs concurrently. 
The Operating System is in charge of providing each process 
with the illusion of a fresh machine for it only, and of 
scheduling all these concurrent processes. In robots, jobs 
not only run concurrently, they heavily collaborate. Each 
job is a part of a complex behavior that emerges from their 
coordination/orchestration. 

To support the development of concurrent programs, ur- 
biscript provides specific control flow constructs. In addition 
to the traditional sequential composition with '; ', urbiscript 
provides the ' , ' connector, which launches the first statement 
in background, and immediately proceeds to executing the 
next statements. Scopes (statements enclosed in curly braces: 
{ si; s2, ...}), are boundaries: a compound statement 
"ends" when all its components did. The following example 
demonstrates these points. 



// "Is" means one second. Launch two commands in 
// background, using Execution flow exits the 

// scope when they are done. 

{ { sleep(2s); echo(2) }, { sleep(ls); echo(l) }, }. 
echo (3) ; 

[00001451] *** 1 
[00002447] *** 2 
[00002447] *** 3 



Other control flow constructs, such as loops, can be exe- 
cuted concurrently. For instance, iterating over a collection 
comes in several flavors: for is sequential while for& 
launches the iterations concurrently (see below). 



for (var i : [2,1,0]) { 
echo("%s: start" % i) ; 
sleep ( i ) ; 

echo("%s: done" % i) 

}; 

echo ( "done" ) ; 

[00125189] ** 
127190] *i 
127190] *i 
128192] *i 
128192] *i 
128193] *i 
128194] *i 



[00] 
[001 
[001 
[001 
[001 
[001 



start 

done 

start 

done 

start 

done 



done 



forS (var i 




[2 


1,0]) { 


echo ( "%s : 


start" % i) ; 


sleep (i) ; 








echo ( "%s : 


done 


' % i) 


) ; 

echo ( "done" ) ; 






[00105789] 




2 


start 


[00105789] 




1 


start 


[00105789] 


* * * 





start 


[00105793] 







done 


[00106793] 


* * * 


1 


done 


[00107793] 




2 


done 


[00107795] 




done 



The standard library also provides functions that launch 
new tasks, running in the background. From an implementa- 
tion point of view, Urbi relies on a library of coroutines [13], 
not system threads. Job control is provided by Tags, whose 
description fall out of the scope of this paper, see [2]. 



II. Events 



A. Basic Events 



Their use goes in three parts. First, an event is needed, a 
derivative from the Event object. This object will serve as 
an identifier for a set of events, it can be used many times 
(or not at all). 



var e = Event. new; 

[00007599] Event_0xl04bcec50 



Second, event handlers are needed. They can catch any 
emission of an event, or filter on the arity of the payload: 



at (e?) 

echo ( "e?" ) ; 
at (e?0) 

echo ("e? () " ) ; 
at (e? (var x) ) 

echo ("e? (%s) " % [x] ) ; 
at (e? (var x, var y) ) 

echo("e?(%s, %s) " % [; 



Finally, we need to emit an event, possibly with a payload. 



e ! ; 




[00000033] * 


** e? 


[00000034] * 


** e? () 


e ! (12, "foo" 


) ; 


[00000035] * 


** e? 


[00000036] * 


** e? (12, foo) 


e ! (12, "foo" 


, 666); 


[00000037] * 


** e? 



The expression e! (arg) is syntactic sugar for 
e . emit (arg) . 

B. Semantics 

The semantics is simple. There is no guarantee on the 
order in which the event handlers are run (or rather the 
order is an implementation detail that is not enforced by our 
language definition). The handling of events is asynchronous 
by default, i.e., the control flow that emitted the event may 
proceed before the event handlers are finished. 



var f = Event. new; 




[00000917] Event_0xl07545d90 




at (f?(var e) ) { echo(e); sleep (0 


5s) ; echo (e) ; } ; 


f ! ( "handler" ) ; echo ( "top" ) ; 




[00000919] *** handler 




[00000928] *** top 




sleep(ls); // Wait for the second 


echo . 


[00001433] *** handler 





Event can be send synchronously to override this behavior. 



f . syncEmit ( "handler" ) ; echo ( "top" ) ; 


[00001929. 


*** handler 


[00002436 


*** handler 


[00002436 


*** top 


Several handlers can run concurrently. 


f ! ("hi") ; 


echo (1); f!("h2"); echo(2); 


[00002437 


* * * hi 


[00002442 


*** l 


[00002442 


*** h2 


[00002448 


*** 2 


sleep (2s) , 




[00002942 


*** hi 


[00002954 


*** h2 



Event handlers may raise events; the system does not en- 
force laws that would prevent endless constructs. We believe 
that soundness properties such as termination guarantees do 
not belong to the Urbi system, but to the programmer. 



var e = Event. new; 




at (e?(var 


p) ) { echo (p) ; e ! 


(-P) J; 


e! (-1) ; 






[00003919] 


*** -1 




[00003925] 


*** l 




[00003931] 


*** -1 




[00003936] 


*** l 




[00003945] 


*** -l 





From the implementation point of view, a major constraint 
was the pressure over the CPU. Because in embedded 
systems (and in particular with low-cost robots) the batteries 
must be saved to all cost, the implementation aims at 
the lowest possible foot-print. There is no active wait: in 
Urbi, if there are no current computations but only event- 
constructs that monitor external events (incoming network 
data, UObjects-generated events etc.), then the system con- 
sumes no CPU at all. 

It is on top of this event-handling layer that urbiscript 
provides its supports for monitoring arbitrary expressions, 
see Section III. 

C. Filtering 

Finally, at clauses can filter on the payload. 



var e = Event. new; 

[00000002] Event_0xADDR 
var x = 12 3; 

[00000003] 123 

at (e? (var x, var y) if x == y) 

echo("e?(%s, %s) with %s == %s" % [x, y, x, y] ) ; 
at (e? (x, var y) ) 

echo("e?(%s, %s) " % [x, y] ) ; 


e ! (12, 34) 






e! (12, 12) 

[00000215] 


* * * 


e? (12, 12) with 12 == 12 


e! (x, 34) 

[00000218] 


* * * 


e?(123, 34) 


e ! (x, x) 

[00000221] 
[00000221] 


* * * 


e?(123, 123) with 123 == 123 
e?(123, 123) 



urbiscript supports pattern-matching, which can be used to 
filter the event payload. Special syntactic support is provided 
for tuples, lists, and dictionaries (and their combinations). 



var e = Event. new; 

[00000206] Event_0xl09324980 

// Filter on lists. 

at (e? ( [1, var y, "foo" ] ) ) 

echo("[l, %s, \"foo\"]" % y) , 
e! (1, 2, "foo") ; 
e! ( [1, 2, "foo"] ) ; 
[00000312] *** [1, 2, "foo"] 



III. Expressions as Events 

The at blocks can also be used to monitor arbitrary 
expressions: 



1; 

)1] 1 



// The absence of question mark indicates we're 
// monitoring an expression, not an event, 
at (x <= 0) 

echoC'x is negative") 
onleave 

echo ("x isn't negative anymore"); 

x = -1; 

[00000002] -1 

[00000003] *** x is negative 
x = -2; 

[00000004] -2 
x = 1; 

[00000005] 1 

[00000006] *** x isn't negative anymore 

This is actually syntactic sugar on top of 
makeEvent ( exp) . It turns any Boolean expression 
into an event that triggers when the expression evaluates to 
true, and stops when it becomes false again. 

A. Durations 

Gostai developed some robotic behaviors using event 
constructs, for instance to trigger some reaction when a ball 
is visible, or ceases to be. Because the object detection is not 
perfect, the robot sometimes appeared to behave erratically. 
This is easy to solve using some hysteresis mechanism, but 
the result is cluttered uses of event constructs. The same 
happens when implementing behaviors such as "do this when 
the head of the robot is patted for two seconds". 

To address this issue urbiscript provides support to monitor 
conditions that are sustained for some specified amount 
of time: the handler may require an event to be sus- 
tained for a given amount of time before being "accepted" 
(at (exp ~ duration) ). The optional onleave clause is 
run when the condition is invalidated. 

var x = ; 

[00001855] 
at (0 < x ~ Is) 

echo("%l.lf: at" % [timed - t0]) 
onleave 

echo("%l.lf: onleave" % [timeO - tO] ) ; 

tO = time () ; 
[00001862] 1.19469 

// x is 1 for 1 second. 

x = 1 ; sleep ( Is ) ; 

[00001863] 1 
[00002865] *** 1.0: at 

// The event was triggered, it is not rerun. 

sleep ( Is ) ; 

// Reset. 

x = 0; 

[00003869] 

[00003869] *** 2.0: onleave 

// x is not positive long enough. 

x = 1; sleep(0.9s); x = 0; sleep (0 . 5s) ; 

[00003874] 1 
[00004777] 

// x is positive long enough. 

x = 1; sleep(0.5s); x = 2; sleep (0 . 5s) ; 

[00005281] 1 
[00005783] 2 
[00006283] *** 4.4: at 



B. Main Usage: Arbitrary Event Monitoring 

The main interest of this feature is to be able to monitor 
in an event-driven way objects without requiring any special 
facility from their part. Consider for instance a "car" object, 
that has a "fuel" slot indicating the remaining fuel level. With 
a classical approach, if we want to trigger an alert when 
we're running out of gas, the car would have to provide an 
adequate event, and trigger it each time the fuel is altered 
and is under a given threshold. 

class Car 

{ 

// The urbiscript constructor, 
function init ( ) { 
var this. fuel = 1; 

// We must manually create a specific 
// event to signal low fuel level . 

var this.lowFuel = Event. new; 

}; 

// We must never update fuel directly, but use 
// this setter, otherwise we might end up not 
// sending the lowFuel event, 
function updateFuel (var v) { 

var previous = fuel; 

fuel = v; 

var threshold = 0.05; 

// We must emit the event only if we just 
// passed below the threshold. 

if (previous >= threshold && v < threshold) 
lowFuel ! ; 

}; 

}; 

[00000735] Car 

var car = Car. new; 

[00000802] Car_0xl09f 322e0 

at (car . lowFuel? ) 

echo ( "Warning, running out of gas!"); 

This method has several cons. It forces the Car imple- 
menter to write a lot of boiler plate code, and to anticipate all 
its user needs and provide the adequate events. For instance 
here we cannot monitor other values of the fuel level. A more 
generic interface would be to provide an event that triggers 
each time the fuel level changes. 

class Car 

{ 

function init() { 
var this. fuel = 1; 

// We must manually create a specific 
// event to signal low fuel level . 

var this . f uelChanged = Event. new; 

}; 

// We must never update fuel directly, but use 

// this setter. 

function updateFuel (var v) { 

var previous = v; 

fuel = v; 

// For convenience, the event carries the 
// previous and current values as payload. 

fuelChanged! (previous, fuel) ; 

}; 

}; 

[00000735] Car 
var car = Car. new; 

[00000783] Car_0xl02ed0990 



// Like before, give a warning on low fuel level, 
at (car . f uelChanged? (var prev, var cur) 
if 0.05 < prev SS cur <= 0.05) 
echo ( "Warning, running out of gas!"); 
// Also, check we do not overfill the tank, 
at (car . f uelChanged? (var prev, var cur) 
if prev < 0.95 SS 0.95 <= cur) 
stopFillingGas ( ) ; 

This approach allows the user to monitor the fuel level 
for any condition. However, the Car implementer still has to 
provide and trigger manually events for changing variables. 
The Car user can monitor the fuel level in any way, but at 
the expense of verbose and complex at constructs. 

With the use of at on arbitrary expressions, we can get 
rid of all these problems: the Car implementer simply uses 
the fuel slot naturally by directly affecting it values. Since 
nothing special has to be done, he cannot forget to provide 
any monitoring event. The user can monitor any condition 
on the fuel slot, in a more concise way. 

class Car 

{ 

function init() { var this, fuel = 0.5 } 

// No wrapper needed, directly update "fuel". 

}; 

[00000735] Car 
var car = Car. new; 

[00000737] Car_0xl02db0d80 

// Car has a fuel level slot, a float. 

car . fuel; 

[00000000] 0.5 

// Although Car wasn't designed to emit fuel 
// events, we can react to its variations, 
at (car. fuel < 0.05) 

echo ( "Warning, almost out of gas!"); 

at (0.95 < car. fuel) 
stopFillingGas () ; 



C. General Purpose Usage: Eased Flow Control 

Another interesting usage of this feature is simplified 
control flow in some situation. We can for instance separate a 
stop condition from an algorithm with an at: the algorithm is 
as soon as the condition is verified. We can then perform the 
algorithm without worrying about checking our exit cases. 

The following function is an example of synchronous flow 
control. It searches a value in a list, sorted (dichotomy) or 
not (linear search). 

function find (var list, var val, var sorted) 
{ 

var begin = 0; 

var end = list. size; 

// First, factor all our stop cases with ats. 

// When we find the element, return its index, 
at (list [begin] == val) 

return begin; 
// When we exhaust our search space, fail, 
at (begin == end) 

return -1; 

// Now only the traversals remain, 
if (sorted) 

// Perform a dichotomy on sorted vectors. 



loop 

{ 

var middle = ((begin + end) / 2) .floor; 
if (list [middle] < val) 

begin = middle + 1 
else 

end = middle 

} 

else 

// Linear search on non-sorted vectors . 
loop 

begin++; 

}; 



D. Implementation 

The main concern is efficiency. A trivial implementation 
would be simple busy-looping: checking at each instant (at 
the end of every scheduler cycle) whether the condition is 
true, and triggering the event if needed. This would work, but 
is of course highly time and space (and energy!) expensive. 

We could check the condition only at a given frequency, 
but then we could miss some events, if the condition becomes 
true and then false again between two checks. Moreover, 
this would imply a potential delay between the realization 
of the condition and the triggering of the at, which can be 
acceptable for reading some robotic sensor, but not in our 
previous vector-search algorithm. This would anyway not be 
optimal, since we would probably end up doing too many 
checks. 

Our implementation uses a "push" model rather than a 
"poll" one: instead of checking the condition arbitrarily to 
see whether it changed, it's the modification of any value that 
might alter the expression that will trigger the reevaluation 
of the expression, and potential triggering of the at block. 
This is optimal, since the condition is reevaluated only if 
there's any chance it changed: if nothing related to your at 
happens, it won't consume any CPU cycle. 

To achieve this, when an at is first declared, the condition 
is evaluated, and any mutable data encountered during this 
evaluation is hooked for modification. Then every time some 
of this data is altered, we reevaluate the condition and trigger 
the at block if needed. When the condition is reevaluated, 
the hooked variables list is also flushed and rebuilt since 
it might differ, if we take another branch of a conditional 
statement for instance. 

var global = false; 

[00000619] false 

function test (var foo) 

( if (global) foo. a == 1 else foo. a == foo.b }; 

var foo = Object. new; 

[00000620] Object_0xl091939d0 
var foo. a = 1; 
[00000621] 1 
var foo.b = 2; 

[00000621] 2 

at ({ echo ( "evaluate" ) ; test (foo) () 

echo ( "True ! " ) 
onleave 

echo ( "False! " ) ; 

[00000001] *** evaluate 



// Hooked variables here are: global, foo, 
// foo. a and foo.b. 

// Altering foo.b triggers an evaluation, 

// but does not alter the result or the hooked 

// variables list. 

foo.b = 3; 

[00000002] *** evaluate 
[00000002] 3 

// Altering global makes the condition true. 

global = true; 

[00000003] *** evaluate 
[00000004] *** True! 
[00000002] true 



// The list of hooked variables is now: 
// foo, foo. a. 



global , 



// Altering foo.b does not trigger a reevaluation, 
// since it no longer participates. 

foo.b = 2; 

[00000006] 2 



IV. Future Work 

A. Handlers Synchronicity 

As of today, urbiscript allows the emission of an event 
to declare whether the event handlers must be performed 
immediately (synchronous), or "later" (asynchronous). But 
experience shows that some patterns are better treated when 
it is on the handler side that synchronicity is chosen. 

B. Congestion Control 

As reported earlier, the (asynchronous) execution of event 
handlers may result in several instances of event handlers 
being run concurrently. Depending on the application this 
might be a feature, or a nuisance. 

There are several ways to process events whose handling is 
long. Similarly to what the clock-directed loops in urbiscript 
already do, bodies could be forbidden to overlap by waiting 
for the previous handler to finish, they might need to be 
preempted by newer event emissions, we could event manage 
some priority scheme, with features that would allow to drop 
obsolete events. 

C. Urbi 

The Urbi platform, as a middleware, already provides 
support for emitting events at the C++ level, independently 
of the urbiscript language. But the reception part is ongoing 
work. 

Conclusion 

We have presented event-driven programming in urbis- 
cript, the programming language of choice to orchestrate 
UObjects (Urbi components). Together with the primitive 
support for concurrency, it is the corner stone for the 
Urbi paradigm for the development of robotic applications. 
Although it bears resemblance to reactive programming lan- 
guages, the urbiscript language is made to make experimenta- 
tion easier by offering more opportunities for the addition of 
feature a posteriori. Expression-based events are one typical 
example: they allow to monitor events in a non-intrusive way, 



without requiring that hooks were previously deployed in the 
monitored objects. 
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